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CROSS-REFERENCE TO RELATED APPLICATION 

This application is related to and incorpomt©sr^6y reference herein the 
commonly owned co-pending U.S. Patept'^?'C^lication Serial Number 
XX/XXX,XXX, entitled "Methpd^and Mechanism for Synchronizing A Slave's 
Timer To A Master' sjjinler," inventor Jack B. Hollins, filed November 30, 1999, 
attorney dock^t-rtumber M-8009 US. 

CROSS-REFERENCE TO SOURCE CODE APPENDIX 

Appendix A and Appendix B, which are part of the present disclosure, 

contain VERILOG source code for implementing one embodiment of this 

invention as described more completely below. 

A portion of the present disclosure contains material that is subject to 

copyright protection. The copyright owner has no objection to the facsimile 

reproduction by anyone of the patent document or the patent disclosure, as it 

appears in the Patent and Trademark Office patent files or records, but otherwise 

reserves all copyright rights whatsoever. 

BACKGROUND 

IEEE 1394 High Performance Serial Bus ("IEEE 1394 standard") provides 
a protocol for a high speed serial bus that supports isochronous data transfer. In 
isochronous data transfer, data is broadcasted on assigned channels with 
guaranteed bandwidth allocation. IEEE 1394 standard is available fi*om the 
Institute of Electrical and Electronic Engineers located at 345 East 47th Street, 
New York, N.Y. 10017-2394. IEEE 1394 standard can be purchased fi-om IEEE's 
web site at http://www.ieee.org/. IEEE 1394 standard is hereby incorporated by 
reference in its entirety. 
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An implementation of IEEE 1394 standard includes a first node 6000 and a 
second node 7000 coupled through a cable 6014 (FIG. lA). Node 6000 includes an 
application logic 6002, a link controller 6004, and a physical layer chip 6006 (also 
called "PHY chip"). Circuitry included in application logic 6002 (Fig. IB) 
5 depends on the application. For example, for a set top box, logic 6002 includes RF 
tuner, IF tuner, forward error correction circuit, MPEG2 transport stream decoder, 
MPEG2 video decoder, MPEG2 audio decoder, smartcard interface, and memory 
(ROM and RAM). Similarly, node 7000 includes another application logic 7002, a 
link controller 7004, and a PHY chip 7006. Link controller 6004 (FIG. IB) 

10 includes a packet transmitter 6008, a packet receiver 6010, and a cycle control 
6012. To transmit data, link controller 6004 makes a bus request to PHY chip 
6006. After winning bus arbitration, PHY chip 6006 informs link controller 6004 
that it has the bus and may transmit data, 

lEC 61 883-4 provides that "[i]f not enough data is available to transmit in 

15 the isochronous packet, then an empty packet shall be transmitted." P. 9. lEC 

61 883-4 also provides that "[i]f for some reason the delay in the transmitter is too 
long, resulting in a time stamp which points in the past (late packet), then this 
source packet is not transmitted." P. 13. lEC 61883-1 provides the details as to 
how to generate a empty common isochronous packet. lEC 61 883-1 and lEC 

2 0 61 883-4 are available from the Intemational Electrotechnical Commission, 3, rue 

de Varembe, P.O. Box 131, CH - 121 1 Geneva 20, Switzerland. lEC 61883-1 and 
lEC 61883-4 can be purchased from lEC's web site at http://www.iec.ch/home- 
e.htm. lEC 16883-1 and lEC 61883-4 are hereby incorporated by reference in its 
entirety. 

25 

SUMMARY 

In accordance with the present invention, a refetch logic coupled between 
an application logic and a link controller selectively passes data from one of two 
data sources in the application logic to the link controller. The link controller uses 

3 0 the data to begin generation of a packet even before receiving control of a medium 

(such as a bus) on which the packet is to be transmitted. In one example, the 
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refetch logic supplies the link controller with data from a first source for generating 
a packet in anticipation of transmission. In the example, prior to transmission of 
the packet, the refetch logic may switch from the first source to a second source if 
necessary. The switch between sources may be necessary, for example, because 
5 there is not enough data provided by the first source for the packet to be formed or 
if the data from the first source is too old to be sent. The ability to switch sources 
allows the link controller to request control of the transmission medium prior to 
receiving from the application logic the data that is to be transmitted (in the case 
when data from the second source which is actually transmitted is sent after data 

1 0 from the first source). 

hi one embodiment, the refetch logic propagates by default the data from a 
first bus of the application logic to the link controller. The link controller reads 
data supplied by the refetch logic and starts to generate a packet. If the application 
logic (containing the two data sources) decides to transmit data from a second bus 

15 prior to transmission of the just-described packet, the refetch logic propagates data 
from the second bus to the link controller. The refetch logic also instructs the link 
controller to discard the just-described packet (formed from data of the first source) 
and to generate a new packet. 

In this embodiment, at the time of providing data from the first source, the 

2 0 refetch logic also makes a request to the link controller to transmit data. The link 
controller then makes a request to a physical layer chip to obtain control of the 
transmission medium on which data is to be transmitted. While waiting to receive 
control of the transmission medium, the link controller reads data from the refetch 
logic and starts to generate a packet. After receiving control of the transmission 

2 5 medium, the link controller transmits a status signal (informing the application 

logic and the refetch logic) that the link controller will start data transmission at a 
specified time in the future. The application logic must decide within the specified 
time whether to continue with data being supplied on the first bus or switch to a 
second bus (by driving a control signal called "data refetch signal"). 

3 0 In one implementation, the refetch logic includes a state machine that 

controls a multiplexer which selectively propagates data from one of the first bus 



-3- 



M-8138 US 




and the second bus to the link controller. The state machine propagates data from 
the first bus to the link controller by default. On receipt of the data refetch signal 
(described above), the state machine propagates data from the second bus to the 
link controller and transmits a control signal (also called "packet discard signal") to 
5 the link controller. The link controller then discards the packet (also called "first 
packet") formed from the data supplied by first bus, and begins to generate a new 
packet (also called "second packet") from the second bus. 

In this implementation, the link controller includes a packet transmitter that 
generates the first packet and also includes a state machine that controls the packet 

10 transmitter. Specifically, the state machine in the link controller causes the packet 
transmitter to discard the first packet on receiving the packet discard signal. 
Thereafter, the packet transmitter generates a second packet from the data received 
from the refetch logic and supplies the second packet to the physical layer chip for 
transmission to another device. In this implementation, the packet transmitter 

1 5 starts transmission of the first packet if the packet discard signal is not received 
within the specified time. 



BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 A illustrates, in a high level block diagram, prior art architecture of 
2 0 IEEE 1394 standard. 

FIG. IB illustrates, in a high level block diagram, a prior art link controller. 
FIG. 2 illustrates, in a high level block diagram, a circuit that includes an 
application logic, a refetch logic, a link controller, and a PHY chip in accordance 
with one embodiment of the present invention. 

2 5 FIG. 3 illustrates, in a block diagram, a refetch logic in accordance with one 

embodiment of the circuit illustrated in FIG. 2. 

FIG. 4 illustrates, in a flow chart, a method used by the circuit illustrated in 
FIG. 2 to change a source of data for isochronous transmission. 

FIG. 5 illustrates, in a timing diagram, the relationship between the 

3 0 transferred signals among a state machine, an application logic, and a link 

controller of FIG. 2 and FIG. 3. 
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FIG. 6 illustrates, in a state diagram, a state machine used to implement the 
refetch logic illustrated in FIG. 3 and the method illustrated in FIG. 4. 

FIG. 7 illustrates, in a block diagram, a portion of a link controller 
illustrated in FIG. 2. 

FIG. 8 illustrates, in a flow chart, a method used by the link controller to 
adapt to the change of a data source for isochronous transmission illustrated in FIG. 
7. 

FIG. 9 illustrates, in a timing diagram, the relationship between transferred 
signals among a second state machine, an application logic, and a PHY chip 
illustrated in FIG. 2 and 7. 

FIG. 1 0 illustrates, in a state diagram, a state machine used to implement 
the link controller in FIG. 7 and the method illustrated in FIG. 8. 



DETAILED DESCRIPTION 

In accordance to IEEE 1394 standard, one node arngfrig a number of nodes 
interconnected by a shared bus is responsible for timc/distribution to the other 
nodes. This node is known as the cycle master. B^iodically the cycle master 
transmits a cycle start packet that is used by omer nodes on the IEEE 1394 bus to 
synchronize their local clocks (also callejJ^CYCLE_TIME register") and define 
the start of the phase in which only iaerchronous packets can be transmitted (also 
called "isochronous phase"). Foy^ exemplary CYCLE_TIME register, see U.S. 
Patent Application Serial Nm^er XX/XXX,XXX, entitled "Method and 
Mechanism for Synchronmng A Slave's Timer To A Master's Timer," by inventor 
Jack B. Hollins, file^^ovember 30, 1999, attomey docket number M-8009 US, 
which is incorporaed by reference above. 

In order to meet the timing requirements to guarantee access to the bus 
before the isochronous phase is over, a link controller must make a bus request as 
soon as possible after the detection of a cycle start packet and the desire for 
isochronous transmission. In order to make timely isochronous bus request, the 
link controller must be made aware of the desire for isochronous transmission and 
packet dependent information necessary for bus request before the isochronous 
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phase begins. This would be straight forward if the packet to be transmitted was 
known before the isochronous phase begins. However, in some isochronous 
applications, events can occur (after the isochronous phase begins but before the 
link controller begins packet transmission) that necessitate a change from a first 
5 packet that the link controller may have begun generating, to a second packet. 

In one embodiment, a node 2 includes a refetch logic 5 (FIG. 2) that enables 
a link controller 6 to fetch data necessary to make a bus request and to generate a 
first packet in anticipation of data transmission from a first source. Refetch logic 5 
ftirther enables an application logic 4 to switch from the first source to a second 

1 0 source when necessary, so that link controller 6 will generate and transmit a second 
packet instead of the first packet. 

Refetch logic 5 selectively passes data from one of two data sources to link 
controller 6. For example, refetch logic 5 supplies link controller 6 with data from 
a first source for generating a packet (also called "first packet") in anticipation of 

15 data transmission, and prior to transmission of the packet refetch logic 5 switches 
from first source to a second source if necessary. Specifically, refetch logic 5 
propagates the data from a first data bus 406 to link controller 6 by default. Link 
controller 6 reads data supplied by refetch logic 5 and starts to generate the first 
packet. If an application decides to transmit data from a second bus 408 prior to 

2 0 transmission of the first packet, refetch logic 5 propagates data from second bus 
408 to link controller 6. Refetch logic 5 also instructs link controller 6 to discard 
the first packet and to generate a new packet (also called "second packet"). 

In one embodiment, application logic 4 drives active a control signal 
(hereinafter "data transmit signal") when desiring data transmission. A line 402 

2 5 carries the data transmit signal to a terminal 501 of refetch logic 5. In response to 

an active data transmit signal, refetch logic 5 requests data transmission by driving 
active another control signal ("hereinafter "transmission request signal"). A line 
502 carries the transmission request signal to a terminal 601 of link controller 6. 

In response to an active transmission request signal, link controller 6 drives 

3 0 another request signal ("hereinafter "medium request signal") to request control of 

a transmission medium 8. A bus 606 carries the medium request signal to a port 
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701 of a physical layer chip 7 (also called "PHY chip"). In response to the medium 
request signal, PHY chip 7 arbitrates for control of transmission medium 8 with 
other devices that share medium 8. PHY chip 7 drives a status signal (hereinafter 
called "medium grant signal") on a bus 702 when link controller 6 has won control 
5 of medium 8. Bus 702 is coupled to a port 609 of link controller 6. In response to 
the medium grant signal, link controller 6 drives active another status signal 
(hereinafter " transmission grant signal") to inform refetch logic 5 and application 
logic 4 that link controller 6 now has control of transmission medium 8. A line 
602 carries the transmission grant signal to a terminal 509 of refetch logic 5 and to 

10 a terminal 401 of application logic 4. 

In one embodiment, application logic 4 has two data buses 406 and 408 that 
are respectively coupled to input ports 505 and 507 of refetch logic 5. Refetch 
logic 5 propagates data from a first data bus 406 to an output bus 506 by default. 
When refetch logic 5 receives an active data refetch signal on a terminal 503, 

15 refetch logic 5 propagates data from a second data bus 408 to output bus 506. 
Terminal 503 is coupled to a line 404 that carries the data refetch signal from 
application logic 4. Refetch logic 5 also drives active a control signal (hereinafter 
"packet discard signal") to instruct link controller 6 to discard the first packet and 
to generate a second packet from new data on output bus 506. A line 504 carries 

2 0 the packet discard signal to a terminal 605 of link controller 6. 

In this embodiment, refetch logic 5 continues to propagate data from data 
bus 408 to output bus 506 until an active signal (hereinafter "transmission finish 
signal") is received on a terminal 511. Data bus 506 is coupled to a port 607 of 
link controller 6. Link controller 6 generates a packet from the data received on 

2 5 port 607. Link controller 6 drives the packet on a bus 608, which is coupled to a 

port 703 of PHY chip 7 and the PHY chip 7 drives the packet on transmission 
medium 8 to other devices. 

In one embodiment, link controller 6 fetches data from output bus 506 
(which carries data from data bus 406 by default) after receiving the active 

3 0 transmission request signal on terminal 601 , and before receiving the medium grant 

signal on port 609, in an act that is also called "prefetching." So, link controller 6 
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reads data from output bus 506 even before application logic 4 has decided what 
data is to be sent on tr£insmission medium 8 (e.g., before deciding whether to 
transmit from data bus 406 or data bus 408). 

In this embodiment, link controller 6 begins to generate the first packet 
5 from the prefetched data in response to receiving the active transmit request signal. 
At the time the transmission request signal is active, output bus 506 carries the data 
from bus 406 by default. In one implementation, for example, application logic 4 
provides on bus 406 a header in the form of the first thirty-two bits of data 42 
(when the transmission request signal is active) that is stored in a first in-first out 

10 (FIFO) buffer 46 (FIG. 3). In one variation, data 42 conforms to the data format 
illustrated in FIG. 1 and FIG. 2 of lEC 61883-4 (incorporated by reference above). 

Link controller 6 of this embodiment reads and uses the header (e.g., the 
first thirty-two bits) of data 42 to start generating the first packet. In one variation, 
the first packet is an isochronous packet conforming to the data format illustrated 

15 in FIG. 6-17 of IEEE 1394 standard (incorporated by reference above). The 
generation of an isochronous packet includes the insertion of an isochronous 
header, a cyclical redundancy check ("CRC") for the isochronous header, the data 
field (e.g., data 42), and a CRC for the data field according to Chapter 6 of IEEE 
1394 standard. 

2 0 In one variation, link controller 6 recovers a speed code included in the first 

thirty-two bits of data 42. Link controller 6 uses the speed code to transmit a bus 
request signal to PHY chip 7. This variation is further described below, in 
reference to FIG. 3 and FIG. 7. 

In one embodiment, node 2 (FIG. 3) includes an application logic 4 that 
25 drives active the data transmit signal (e.g. signal "Isoxmitp" in FIG. 3) to request 
data transmission. In one embodiment, application logic 4 requests isochronous 
transmission in conformance to IEEE 1394 standard. Line 402 carries signal 
Isoxmitp to a terminal 513 of a state machine 52. In response to the active signal 
Isoxmitp, state machine 52 drives active the transmission request signal (e.g., in 

3 0 FIG. 3, signal "Isopktreqn"). 
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In this embodiment, state machine 52 causes a multiplexer 54 to propagate 
data from data bus 406 (received on a port 521) to output bus 506 by default. State 
machine 52 causes multiplexer 54 to propagate data from data bus 408 (received on 
port 523) to output bus 506 when state machine 52 receives an active data refetch 
5 signal (e.g. signal "Refetch_conditionp" in FIG. 3) on a terminal 515 coupled line 
404. State machine 52 causes multiplexer 54 to propagate signals from bus 408 to 
bus 506 by driving active a mux control signal (e.g., in FIG. 3, signal 
"Isosourceselp") on a line 508 coupled to a control terminal 525 of multiplexer 54. 
State machine 52 drives the mux control signal active until it receives an active 
10 transmission finish signal (e.g., in FIG. 3, signal "Confirmn") on a terminal 519 
coupled to line 604. 

Depending on the implementation, any one of various requirements that 
depend on a specific standard being implemented (e.g., lEC 61883-4 may require 
that a stale or incomplete packet in the packet transmitter to be disc£irded and be 
15 replaced with a new packet) or the specific application (which may be doing flow 
control or be too slow in generating data 42) can cause application logic 4 to drive 
the data refetch signal active, thereby to switch from data bus 406 to data bus 408. 

In one embodiment, application logic 4 must decide to switch from data bus 
406 to data bus 408 within a specified time (also called "refetch time") after 

2 0 receiving an active transmission grant signal (e.g., in FIG. 3, signal "Isogntp") on 

terminal 401 , Otherwise link controller 6 begins transmission of the first packet 
formed from data prefetched from bus 506. In one implementation, the first packet 
is an isochronous packet in conformance with IEEE 1394 standard. 

State machine 52 informs link controller 6 of any change in the data source 
25 so that link controller 6 can discard a first packet generated from prefetched data 
and generate a second packet from the data on bus 408. If such change is not 
supported, the first packet generated by link controller 6 is defective because of the 
change in data source. 

State machine 52 drives active packet discard signal (e.g., in FIG. 3, signal 

3 0 "Isorefetchp") to inform link controller 6 of the switch from data bus 406 to data 

bus 408. As previously described, link controller 6 waits for a specified time, e.g.. 



-9- 



M-8138 US 




the refetch time, before starting data transmission. During the refetch time, 
application logic 4 may decide to switch from data bus 406 to bus 408 and instruct 
state machine 52 to drive the packet discard signal active. After link controller 
finishes data transmission, link controller 6 drives the transmission finish signal 
5 active to indicate that state machine 52 can once again request data transmission. 

State machine 52 starts with action 82 (FIG. 4) and initializes all signals as 
inactive. Action 82 is followed by action 84. In action 84, state machine 52 
determines if application logic 4 requests data transmission. Application logic 4 
drives active the data transmit signal (e.g., in FIG. 3, signal "Isoxmitp") if it desires 

10 data transmission. Action 84 is followed by action 86 if state machine 52 receives 
an active signal Isoxmitp at terminal 513. Otherwise, action 84 loops back to itself 
to wait for an active signal Isoxmitp. 

In action 86, state machine 52 drives an active signal Isopktreqn on line 502 
to request isochronous transmission from link controller 6. Action 86 is followed 

15 by action 88. In action 88, state machine 52 determines if link controller 6 has 

control of transmission medium 8 for data transmission. State machine 52 receives 
an active signal Isogntp on terminal 5 1 7 if link controller 6 has control of 
transmission medium 8. Action 88 is followed by action 90 if link controller 6 has 
control of transmission medium 8. Otherwise, action 88 loops back to itself to wait 

2 0 for an active signal Isogntp. 

In action 90, state machine 52 determines if application logic 4 wishes to 
switch the source of data from data bus 406 to data bus 408. State machine 52 
receives an active signal Refetch_conditionp on terminal 5 1 5 if application logic 4 
wishes to switch from data bus 406 to data bus 408. Action 90 is followed by 
25 action 94 if application logic 4 wishes to switch the data source. Otherwise, action 
90 is followed by action 92. 

In action 92, state machine 52 waits for link controller 6 to finish data 
transmission. State machine 52 receives an active signal Confirmn on terminal 519 
when link controller 6 finishes data transmission. Action 92 is followed by action 

3 0 84. In action 94, state machine 52 causes multiplexer 54 to propagate data from 

bus 408 to bus 506. Action 94 is followed by action 92. 
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In one example, at time tO (FIG. 5) application logic 4 drives active signal 
Isoxmitp to indicates its desire for data transmission. Signal Isoxmitp remains 
active imtil application logic 4 does not desire data transmission. At time tl, state 
machine 52 drives active signal Isopktreqn to request isochronous transmission on 
5 transmission medium 8 in response to the active signal Isoxmitp. Signal 
Isopktreqn remains active as long as signal Isoxmitp is active. At this time, 
multiplexer 54 propagates data from port 525 (coupled to data bus 406, also called 
"first source") to output bus 506 because signal Isosourceselp is inactive. Signal 
Isosourceselp is inactive because state machine 52 has yet to receive an active 

1 0 signal Refetch_conditionp. 

Between time tl and time t3, state machine 52 waits for the result of the bus 
arbitration. At time t3, state machine 52 receives an active signal Isogntp. The 
active signal Isogntp indicates that link controller 6 has control of transmission 
medium 8 and that link controller 6 will wait for an active signal Isorefetchp for a 

15 specified time, i.e., the refetch time (e.g., 4 clock cycles), before starting 

isochronous transmission to PHY chip 7. In one implementation, transmission 
medium 8 is a serial bus in conformance with IEEE 1394 standard. 

At time t3, state machine 52 drives active signal Isosourceselp in response 
to receiving an active signal Refetch_conditionp and the active signal Isogntp. 

2 0 Signal Refetch conditionp remains active until a specified condition that requires 
the switch from data bus 406 to data bus 408 no longer exits. Multiplexer 54 
propagates signals from port 523 (coupled to data bus 408) to data bus 506 in 
response to the active signal Isosourceselp. As illustrated in FIG. 5, multiplexer 54 
propagates, and link controller 6 receives, data from data bus 408 (also called 

2 5 "second source") from time t4 to time t5 because signal Isosourceselp is active. 

Also at time t3, state machine 52 drives active signal Isorefetchp in response to the 
active signal Refetch_conditionp and the active signal Isogmtp. 

Active signal Isorefetchp informs link controller 6 that the data source has 
changed and that link controller 6 must discard the first packet formed from 

3 0 prefetched data and generate the second packet. The time period from time t3 to 

time t5 is for example the specified time (the refetch time) within which 
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application logic 4 must decide to change from data bus 406 to data bus 408. As 
shown in FIG. 5, link controller 6 starts to transmit the second packet at time t5, 
which is the end of the refetch time. 

At time t7, state machine 52 receives an active signal Confirmn that 
5 indicates link controller has finished transmitting the second packet and that state 
machine 52 can again request data transmission on transmission medium 8. As 
shown in FIG. 5, application logic 4 continues to drives active signal Isoxmitp to 
indicate its desire for data transmission and state machine 52 drives continues to 
drive signal Isopktreqn active in response to the active signal Isoxmitp. 

10 At time t9, state machine 52 receives an active signal Isogntp, indicating 

that link controller 6 has control of the bus and that link controller 6 will await an 
active signal Isorefetchp for a specified time, i.e., refetch time, before starting data 
transmission to PHY chip 7. As the timing diagram illustrates, link controller 6 
continues to receive data from data bus 406 (first source) because signals 

1 5 Refetch_conditionp, Isosourceselp, and Isorefetchp are inactive from time t8 to 

time tl4. As the timing diagram shows, link controller 6 starts to transmit the first 
packet at time tl 1, which is the end of the refetch time. At time t9, state machine 
drives signal Isopktreqn inactive in response to an inactive signal Isoxmitp. 

At time tl3, state machine 52 receives an active signal Confirmn, indicating 

2 0 link controller 6 has transmitted the first packet and that state machine 52 can once 

again request data transmission. However, state machine 52 does not make another 
request (drive active signal Isopktreqn) at time tl4 because application logic 4 no 
longer desires data transmission (inactive signal Isoxmitp). 

A state diagram (FIG. 6) provides that state machine 52 starts in state 1 
25 (also called "1st start state"). State machine 52 transitions from state 1 to state 2 
(also called "data transmission state") on receiving an active signal Isoxmitp on 
terminal 513. During transition from state 1 to state 2, state machine 52 drives an 
active signal Isopktreqn on line 502. The condition and action of this transition are 
captioned in box 96. 

3 0 State machine 52 transitions from state 2 to state 3 (also called "1st wait 

state") after receiving an active signal Isogntp on terminal 517. During transition 
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from state 2 to state 3, state machine 52 drives active signal Isopktreqn, and 
inactive signal Isosourceselp and signal Isorefetchp. The condition and action of 
this transition are captioned in box 98. 

State machine 52 transitions from state 3 to state 1 after receiving an active 
5 signal Confirmn on terminal 519. During transition from state 3 to state 1, state 
machine 52 drives inactive the foUov^ng: signal Isosourceselp, signal Isopktreqn, 
and signal Isorefetchp. 

State machine 52 transitions from state 2 to state 4 (also called "refetch 
state") on receiving an active signal Refetch_conditionp. During transition from 
10 state 2 to state 4, state machine 52 drives active signal Isosourceselp on line 508 

and signal Isopktreqn on line 502. The conditions and actions of this transition are 
O captioned in box 4 02 . 

,g State machine 52 transitions from state 4 to state 1 after receiving an active 

; signal Confirmn on terminal 519. State machine 52 transitions from state 4 to state 

53 15 5 by driving inactive the following: signal Isosourceselp, signal Isopktreqn, and 

1^ signal Isorefetchp. 

1^ In one embodiment, node 2 (FIG. 2) conforms to lEC 61883-4 standard. In 

^ accordance to a condition of lEC 61883-4, a transmitter that is active in using 

-J transmission medium 8, e.g., an application logic 4 that requests isochronous 

[% 2 0 transmission, must transmit a packet containing data in every cycle of a 

predetermined frequency, e.g., 8kHz or 125 microseconds. Otherwise, such a 
transmitter must transmit an empty packet, also called empty "common 
isochronous packet" abbreviated empty "CIP", if there is not enough data to 
transmit a data packet, 
25 There may not be enough data to generate a data packet, e.g., if application 

logic 4 generates less data within a single cycle than a bandwidth allocated to 
application logic 4 (by an IEEE 1394 isochronous resource manager), in which 
case data generated in two or more cycles may be transmitted in a single packet 
which is preceded and followed by empty CIPs. 
3 0 In this embodiment, application logic 4 supplies either data 42 (FIG. 3) on 

data bus 406 or data 44 of an empty CIP packet on data bus 408. As noted above. 
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application logic 4 may decide to transmit data 44 instead of data 42 if there is not 
enough data to transmit an isochronous packet. If so, application logic 4 drives an 
active signal Refetch_conditionp on line 404 to refetch logic 5. Application logic 4 
must determine this condition within the specified time after receiving an active 
signal Isogntp on terminal 401 because thereafter link controller 6 starts 
isochronous transmission of the packet. 

State machine 52 causes multiplexer 54 to propagate the empty CIP packet 
signals from data bus 408 to data bus 506 in response to an active signal 
Refetch_conditionp. State machine 52 also drives an active signal Isprefetchp on 
line 504 to instruct link controller 6 to discard the first packet formed from 
prefetched data 42 from output bus 506. 

In one implementation, application logic 4 stores data 42 in a first in-first 
out buffer (FIFO) 46, where the output of first in-first out buffer 46 is data bus 406. 
Application logic 4 uses a storage level indicator of first in-first out buffer 46 to 
determine if there is enough data to transmit an isochronous packet in accordance 
to lEC 61 883-4. Application logic also includes a bit pattern generator 48 that 
generates an empty CIP packet in accordance to lEC 61883-1, where the output of 
bit pattem generator 48 is provided on data bus 408. If application logic 4 
determines within the refetch time that there is not enough data, application logic 4 
drives an active signal Refetch_conditionp. 

In this implementation, application logic 4 also recovers a time stamp from 
a header from data 42. lEC 61883-4 requires that data with a time stamp that 
points in the past ("late packet") should not be transmitted. Thus, application logic 
4 compares the recovered time stamp to the current cycle time stored in a cycle 
control 68 (FIG. 7) to determine if data 42 should be transmitted. Application 
logic 4 drives an active signal Refetch_conditionp if data 42 is not to be 
transmitted. 

For an exemplary cycle control 68, s^i^^CT^. Patent Application Serial 
Number XX/XXX,XXX, entitled "^(ieffiod and Mechanism for Synchronizing A 
Slave's Timer To A Master^s^Tuner," by inventor Jack B. Hollins, filed November 
30, 1999, attorney dpelcet number M-8009 US, which is incorporated herein by 
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reference in its entirety. Note that aij^tfier cycle control is used in another 
embodiment. Furthermore, m^ym another embodiment, application logic 4 drives 
signal Refetch_conditipilpactive under other conditions, such as availability of 
data following ^:>e^ove-described "late packet." 

In one embodiment, link controller 6 (FIG. 7) includes a state machine 62. 
State machine 62 includes a terminal 61 1 coupled to receive signal Isopktreqn on 
line 502. In response to an active signal Isopktreqn on terminal 611, state machine 
62 drives an active signal Isolreqp on line 616 to request a PHY-link interface 69 to 
transmit a bus request to PHY chip 7. Line 616 is coupled to terminal 629 of PHY- 
link interface 69. 

In response to an active signal Isolreqp on terminal 629, PHY-link interface 
69 drives signal LReq on bus 606 to PHY chip 7. An example of signal LReq is a 
seven bit bus request signal conforming to the requirements of Annex J of IEEE 
1394 standard. In this example, signal LReq has a start bit, a three bit request type 
field, a two bit request speed field, and a stop bit. An active signal Isolreqp 
indicates to PHY-link interface 69 that the request type field is to be filled with a 
code for arbitration of isochronous transmission. A dedicated line (also called 
"speed code line") 410 fi-om application logic 4 provides to PHY-link interface 69 
a speed code. 

In one variation, link controller 6 recovers a speed code firom the header 
(e.g., the first 32 bits) of data 42 read fi-om output bus 506. In the example, a 
packet transmitter 64 that is included in link controller 6 recovers the speed code 
from the first 32 bits of data 42 and transmits the speed code on a line 622 coupled 
to a terminal 633 of PHY-link interface 69 that is included in link controller 6. 
PHY-link interface 69 includes the speed code in signal LReq to PHY chip 7 to 
arbitrate for transmission medium 8. 

Upon winning arbitration, PHY chip 7 drives signal Ctl on line 702 to 
inform link controller 6 of the result. Signal Ctl is, for example, a two bit status 
signal formatted in accordance to Annex J of IEEE 1394 standard. Line 702 is 
coupled to port 635 of PHY-link interface 69. In response to the signal Ctl, PHY- 
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link interface 69 drives an active signal Arbgntp on line 618. Line 618 is coupled 
to terminal 615 of state machine 62. 

In response to an active signal Arbgntp, state machine 62 drives active the 
signal Isogntp on line 602 to inform application logic 4 and refetch logic 5 that link 
5 controller 6 has control of transmission medium 8. Line 602 is coupled to terminal 
509 of refetch logic 5 and terminal 623 of packet transmitter 64. 

After driving signal Isogntp active, state machine 62 drives signal Discardp 
active on line 610 if state machine 62 receives an active signal Isorefetchp on 
terminal 613 prior to receiving an active signal Refetchtimeoutp on terminal 619. 

1 0 An active signal Discardp instructs packet transmitter 64 to discard the first packet 
formed fi-om prefetched data received on port 625, which is coupled to bus 506 of 
refetch logic 5. State machine 62 does not drive signal Discardp active if state 
machine 62 receives an active signal Refetchtimeoutp. 

Terminal 623 of packet transmitter 64 is coupled to line 602 carrying signal 

15 Isogntp. In response to an active signal Isogntp, packet transmitter 64 waits for a 
predetermined time (also called "specified time" or "refetch time"), e.g., 4 clock 
cycles. If packet transmitter 64 receives an active signal Discardp on terminal 621 
within the specified time, packet transmitter 64 does the foUov^ng: (1) discard the 
first packet formed from prefetched signals received on port 625 (coupled to bus 

2 0 506) and (2) generate and transmit the second packet formed from data received on 
port 625. If packet transmitter 64 does not receive an active signal Discardp on 
terminal 621 within the specified time, packet transmitter 64 (1) transmits the first 
packet on a bus 620 coupled to a terminal 627 of PHY-link interface 69 and (2) 
drives active signal Refetchtimeoutp on line 614 coupled to terminal 619 of state 

2 5 machine 62 to indicate that data transmission has started. Under either condition, 

packet transmitter 64 drives signal Endxmitp active on line 612 after transmitting 
one packet. Line 612 is coupled to terminal 617 of state machine 62. 

In response to an active signal Endxmitp on terminal 617, state machine 62 
drives active signal Confirmn on line 604 to inform refetch logic 5 that data 

3 0 transmission is complete and that refetch logic 5 can once again request data 

transmission. 
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State machine 62 (FIG. 8) starts in action 106 and initializes all signals as 
inactive. Action 106 is followed by action 108. In action 108, state machine 62 
determines if refetch logic 5 desires to transmit data. State machine 62 receives an 
active signal Isopktreqn on terminal 601 if refetch logic 5 desires data 
5 transmission. Action 108 is followed by action 1 10 if refetch logic 5 desires to 

transmit data. Otherwise, action 108 loops back to itself to wait for an active signal 
Isopktreqn. 

In action 110, state machine 62 drives active signal Isolreqp on line 616. 
An active signal Isolreqp instructs PHY-link interface 69 to request PHY chip 7 for 

10 isochronous transfer on transmission medium 8. Action 1 10 is followed by action 
112. In action 112, state machine 62 determines if link controller 6 has control of 
bus 8 for data transmission. Link controller 6 has control of transmission medium 
8 if state machine 62 receives an active signal Arbgntp on terminal 615. Action 
1 10 is followed by action 1 14 if state machine 62 receives an active signal Arbgntp 

15 on terminal 615. Otherwise, action 1 10 loops back to itself to wait for an active 
signal Arbgntp. 

In action 114, state machine 62 informs refetch logic 5 that link controller 6 
has control of bus 8. To do so, state machine 62 drives active signal Isogntp on 
line 602. Action 1 14 is followed by action 1 16. In action 116, state machine 62 
2 0 determines if, prior to a predetermined time, refetch logic 5 instructs packet 
transmitter 64 to discard the first packet formed from prefetched data. The 
predetermined time corresponds to a time period after state machine 62 drives an 
active signal Isogntp on line 602 and before state machine 62 receives an active 
signal Refetchtimeoutp on terminal 515. Action 1 14 is followed by action 1 18 if, 

2 5 prior to the predetermined time, refetch logic 5 instructs packet transmitter 64 to 

discard a portion of the first packet formed from prefetched data. Otherwise, 
action 1 14 is followed by action 120. 

In action 118, state machine 62 instructs packet transmitter 64 to discard the 
first packet formed from prefetched signals from port 625. To do so, state machine 

3 0 62 drives active signal Discardp on line 610. Action 1 1 8 is followed by action 120. 

In action 120, state machine 62 waits for packet transmitter 64 to finish 
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isochronous transmission. State machine 62 receives an active signal Endxmitp on 
terminal 617 when packet transmitter 64 finishes isochronous transmission. Action 
120 is followed by action 122. In action 122, state machine 62 informs refetch 
logic 5 that it can once again request isochronous transmission. To do so, state 
5 machine 62 drives an active signal Confirmn on line 604. 

In one example, at time tlOl (FIG. 9), refetch logic 5 drives signal 
Isopktreqn active to request data transmission on transmission medium 8. At time 
tlOl, state machine 62 drives active signal Isolreqp on line 616 to request control 
of transmission medium 8 in response to the active signal Isopktreqn. 

10 From time tlOl to time tl03, state machine 62 waits the result of the bus 

arbitration. At time tl03, state machine 62 receives an active signal Arbgntp 
indicating that link controller 6 has control of transmission medium 8. Also at time 
tl03, state machine 62 drives signal Isogntp active on line 602 in response to the 
active signal Arbgntp. An active signal Isogntp indicates to refetch logic 5 that link 

15 controller 6 has transmission medium 8 and will wait for an active signal 
Isorefetchp for a specified time period (e.g., 4 clock cycles) before starting 
isochronous transmission to PHY chip 7. 

At time tl04, state machine 62 receives an active signal Isorefetchp on 
terminal 613. As the timing diagram shows, state machine 62 receives the active 

20 signal Isorefetchp prior to receiving an active signal Refetchtimeoutp on terminal 
619 at time tl06. Thus, state machine 62 drives an signal Discardp active on line 
610 to instruct packet transmitter 64 to discard the first packet formed fi*om 
prefetched data and to generate the second packet from data received on port 625. 
As the timing diagram shows, packet transmitter 64 receives data from the second 

2 5 source (bus 408) and the link controller generates the second packet from time tl05 

to time 1 108. 

At time tl07, state machine 62 receives a signal Endxmitp active on 
terminal 617. An active signal Endxmitp informs state machine 62 that data 
transmission is complete. At time tl07, state machine 62 drives signal Confirmn 

3 0 active on line 604 in response to the active signal Endxmitp. An active signal 

Confirmn informs refetch logic 5 that it may once again request isochronous 
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transmission. As FIG. 9 illustrates, link controller 6 transmits a second packet after 
tl065 which is the end of the refetch time. 

At time tl09, state machine 62 receives an signal Isopktreqn active on 
terminal 611. Also at time tl09, state machine 62 drives signal Isolreqp active on 
5 line 616 to request control of transmission medium 8 in response to the active 
signal Isopktreqn. As FIG. 9 illustrates, link controller 6 transmits a first packet 
after tl 1 5, which is the end of the refetch time. 

At time tl 15, state machine receives signal Refetchtimeoutp active at 
terminal 619 prior to receiving an active Isorefetchp signal. Accordingly, state 

1 0 machine 62 no longer discards the first packet formed from prefetched data. 

State machine 62 (FIG. 10) starts in state 5 (also called "2nd start state"). 
State machine 62 transitions from state 5 to state 6 (also called "bus request state") 
on receiving an active signal Isopktreqn on terminal 611. To transition from state 1 
to state 2, state machine 62 drives signal Isolreqp active on line 616. The condition 

15 and action of this transition are captioned in box 124. 

State machine. 62 transitions from state 6 to state 7 (also called "2nd wait 
state") on receiving an active signal Arbgntp on terminal 615. To transition from 
state 2 to state 3, state machine 62 drives signal Isogntp active on line 602. The 
condition and action of this transition are captioned in box 126. 

20 State machine 62 transitions from state 7 to state 8 (also called "3rd wait 

state") on receiving an active signal Isorefetchp on terminal 613 prior to receiving 
an active signal Refetchtimeoutp on terminal 619. If this condition occurs, state 
machine 62 drives signal Discardp active on line 610 during the transition from 
state 7 to state 8. The conditions and action of this transition are captioned in box 

25 128. 

State machine 62 also transitions from state 7 to state 8 on receiving an 
active signal Refetchtimeoutp on terminal 619 prior to receiving an active signal 
Isorefetchp on terminal 613. If this occurs, state machine 62 drives inactive the 
following during the transition from state 7 to state 8: signal Isogntp, signal 
3 0 Confirmn, signal Discardp, and signal Isolreqp. The conditions and actions of this 
transition are captioned in box 130. 
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State machine 62 transitions from state 8 and state 5 on receiving an active 
signal Endxmitp on terminal 617. To transition from state 4 and 5 to state 1, state 
machine 62 drives signal Confirmn active on line 604. The condition and action 
for these transitions are captioned in box 132. 



herein will be apparent to the skilled artisan in view of the disclosure. For 
example, state machine 52 and state machine 62 can be included in a single state 
machine that has all their functionality. Furthermore, state machine 52 and state 
machine 62 can be used with other standards which have different conditions for 
10 switching a data source. Numerous such changes and modifications are 
encompassed by the attached claims. 



5 



Numerous modifications and adaptations of the embodiments described 
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50 



APPENDIX A 

******** 

5 

★ 

* 

* 

* Description: This module implements isorefetch mechanism 
10 * 

* * 
**************************************************** 
***** I 

15 // %w% 

"timescale 1 ns / 1 ns 
module applogic ( resetp , 
clkp , 
isoxmitp , 
2 5 isogntp , 

confirmn , 

y ref etch_conditionp , 

I 30 

isopktreqn , 
isorefetchp , 
\ 3 5 isosourceselp ) ; 

,i 

] // from application logic 

input clkp ; // clock 



40 

input resetp ; // reset 

// from software writtable register 

input isoxmitp ; // iso transmission initiate control 

// from 1394 link layer controller 

input isogntp ; // actual transmission is about to begin 

input confirmn ; // transmission is complete 

// from application logic 

input ref etch_conditionp ; // default source invalid 

55 // to 1394 link layer controller 

output isopktreqn ; // request for iso transmission 

output isorefetchp ; // packet source has changed, discard 

any 

6 0 // prefetched data and read from 

start of 



-21- 



M-8138 US 



35 



// packet 

// to application logic 

output isosourceselp ; // link layer controller packet 
output 

// source selector 



10 //*******************★**★******* PART^METERS 

parameter FF_DEIjAY = l; 

// ****************************** j^EG 
]_5 **************************************** 



reg ctl_isopktreqn ; 

2 0 reg ctl_isoref etchp ; 

reg ctl_isosourceselp ; 
reg [3:0] stateap ; 

25 

reg isopktreqn ; 

reg isorefetchp ; 

3 0 reg isosourceselp ; 



reg idle ; 

reg transmitreq ; 

reg transmitdef ault ; 

^ reg transmitsecondary ; 

kQ 4 0 wire [3:0] nextstateap ; 

wire IDLE ; 

wire TRANSMITREQ ; 

45 

wire TRANSMITDEFAULT ; 

wire TRANSMITSECONDARY ; 

50 

assign IDLE = stateap [0] ; 

assign TRANSMITREQ =s stateap [1] ; 

55 assign TRANSMITDEFAULT = stateap [2] ; 

assign TRANSMITSECONDARY = Stateap [3] ; 

assign nextstateap [0] = idle ; 

60 

assign nextstateap [1] = transmitreq ; 
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assign nextstateap [2] = transmitdef ault ; 
assign nextstateap [3] = transmitsecondary ; 



always ® ( posedge clkp ) 
begin 

10 if ( resetp ) 

begin 

stateap <= #FF_DELAY 4 'hi ; 
end 
else 

15 begin 

stateap <= #FF_DEIjAY nextstateap ; 

end 

end 

2 0 * always ® { posedge clkp ) 

begin 

if ( resetp ) 
begin 

isopktreqn <= #FF_DELAY I'bl 
25 isorefetchp <= #FF_DELAY I'bO 

isosourceselp <= #FF_DELAY l*bO ; 
end 
else 
begin 

3 0 isopktreqn <= #FF_DEIiAY ctl_isopktreqn ; 

isorefetchp <- #FF_DELAY ctl_isoref etchp ; 
isosourceselp <= #FF_DELAY ctl_isosourceselp 

end 

3 5 end 



always @ ( /*AUTOSENSE*/lDLE or TRANSMITDEFAULT or TRANSMITREQ 

or TRANSMITSECONDARY or confirmn or isogntp or isoxmitp 
4 0 or ref etch_conditionp) 

begin 

// initialization prevents latches 
idle = I'bO ; 
4 5 transmitreq = I'bO ; 

transmitdef ault = I'bO ; 
transmitsecondary = I'bO ; 

ctl_isopktreqn = I'bl ; 
50 ctl_isoref etchp = I'bO ; 

ctl_isosourceselp = I'bO ; 

case (I'bl) 

55 IDLE : casez ( isoxmitp ) 

I'bO : idle = I'bl ; 

I'bl : transmitreq = I'bl ; 

60 

//summit modcovoff -b 
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default : idle = I'bx ; 
//summit mode o von -b 

endcase // casez { isoxmitp ) 

5 TRANSMITREQ : casez ( { isogntp , ref etch_conditionp } ) 

2'bO? : begin 

transmitreq = I'bl ; 
ctl_isopktreqn = I'bO ; 
10 end 

2'blO : begin 

transmitdef ault = I'bl ; 
ctl_isopktreqn = I'bO ; 
15 end 

2 * bll : begin 

transmitsecondary = 1 * bl ; 
ctl_isopk:treqn = l*bO ; 
2 0 ctl_isoref etchp = I'bl ; 

ctl_isosourceselp = I'bl ; 
end 

//summit modcovoff -b 

2 5 default : transmitreq = l*bx ; 

//summit modcovon -b 

endcase // casez ( { isogntp , ref etch_conditionp } 

) 

30 

TRANSMITDE FAULT : casez ( confirmn ) 
I'bO : idle = I'bl ; 

3 5 1 • bl : begin 

transmitdef ault = I'bl / 
ctl_isopktreqn = I'bO ; 
end 

4 0 //summit modcovoff -b 

default : transmitdef ault = I'bx ; 
//summit modcovon -b 

endcase // casez ( confirmn ) 

4 5 TRANSMITSECONDARY : casez ( confirmn ) 

I'bO : idle = I'bl ; 

I'bl : begin 
50 transmitsecondary = I'bl ; 

ctl_isopktreqn = I'bO ; 
ctl_isosourceselp = I'bl ; 
end 

55 //summit modcovoff -b 

default : transmitsecondary = I'bx ; 
//summit modcovon -b 

endcase // casez { confirmn ) 



60 



default : begin // snafu: if no state bit set 
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idle = I'bx ; 
transmitreq = 1 ' bx ; 
transmitdef ault = I'bx ; 
transmitsecondary = I'bx ; 

5 

ctl_isopktregn = I'bx ; 
ctl_isoref etchp = I'bx 
ctl_isosourceselp = I'bx ; 
end 

10 endcase // case(l'bl) 

end 
endmodule 

15 



=0 
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APPENDIX B 

/**★************************★**★*******★*********** ************* 
******** 
* 

* 



* Description: This module implements isorefetch mechanism (link 
10 side) * 

* * 

****************************************************************** 
****** / 

15 

// %w% 

"timescale 1 ns / 1 ns 

2 0 module linklogic ( resetp , 

clkp , 

isopktreqn , 

25 

isorefetchp , 
arbgntp , 

3 0 endxmitp , 

ref etchtimeoutp , 
isogntp , 

35 

confirmn , 
isolreqp , 

4 0 discardp 

) ; 

4 5 input resetp ; // reset 

input clkp ; // clock 

5 0 // from application logic 

input isopktreqn ; // request for iso transmission 

input isorefetchp ; // packet source has changed, discard 

any 

55 // prefetched , data and read from 

start of 

// packet 

// from phy/link interface 
input arbgntp ; 

60 
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4 




// from link transmitter 

input endxmitp ; // transmission finished 

5 input ref etchtimeoutp ; // window for refetch assertion is 

closed 

// to application logic 
10 output conf irmn ; // transmission is complete 

// to phy/link interface 

15 output isolreqp ; // generate iso Ireq 

// to application logic & link transmitter 

output isogntp ; // actual transmission is about to begin 



20 



25 



30 



35 



40 



45 



50 



55 



60 



output discardp ; //asserted if isorefetchp asserted from 
application 

// logic 



^^*-ie-ie*-ie**-iritiit***ir'k'k-k'k'k-k*ir'k'k*ir-kir*ie PARAMETERS 
********** ********************** ********** 

parameter FF_DEIjAY = 1 ; 

/ / ****************************** REG 
*********** * * *************************** 



reg 


ctl_isogntp ; 


reg 


ctl_confirmn ; 


reg 


ctl_isolreqp ; 


reg 


ctl_discardp ; 


reg [3:0] 


stateap ; 


reg 


isogntp ; 


reg 


conf irmn ; 


reg 


isolreqp ; 


reg 


discardp ; 


reg 


idle ; 


reg 


waitforgnt ; 


reg 


ref etchwindow 


reg 


transmit ; 
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10 



wire [3:0] 

wire 

wire 

wire 

wire 



nextstateap ; 

IDLE ; 

WAITFORGNT ; 
REFETCHWINDOW ; 
TRANSMIT ; 



15 



20 



25 



30 



assign IDLE = stateap[0] ; 
assign WAITFORGNT = stateap[l] ; 
assign REFETCHWINDOW = stateap[2] ; 
assign TRANSMIT = stateapC33 ; 
assign nextstateap [0] = idle ; 
assign nextstateap [1] = waitforgnt ; 
assign nextstateap [2] = ref etchwindow 
assign nextstateap [3] = transmit ; 



35 



40 



45 



50 



55 



60 



always @ ( posedge clkp ) 
begin 

if { resetp ) 
begin 

stateap <= #FF__DELAY 4 'hi ; 
end 
else 
begin 

stateap <= #FF_DELAY nextstateap 

end 

end 



always i 
begin 
if 



( posedge clkp ) 



( resetp ) 
begin 
isogntp 
conf irmn 
isolreqp 
discardp 
end 
else 
begin 
isogntp <= 
conf irmn <= 
isolreqp <= 
discardp <= 
end 



= #FF_DELAY I'bO 
<= #FF_DELAY 1 ' bl 
= #FF_DELAY I'bO 
= #FF DELAY 1 'bO 



#FF_DELAY ctl_isogntp ; 
#FF_DELAY ctl_confirmn 
#FF_DELAY ctl_isolreqp 
#FF_DELAY ctl_discardp 
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end 



always @ (/*AUTOSENSE*/IDLE or REFETCHWINDOW or TRANSMIT or 
WAITFORGNT 

or arbgntp or endxmitp or isopktreqn or isorefetchp 
or ref etchtimeoutp) 



// initialization prevents latches 
idle = I'bO ; 
waitforgnt = l*bO ; 
ref etchwindow = 1 ' bO ; 
transmit = I'bO ; 

ctl_isogntp = I'bO ; 
ctl_conf irmn - l*bl ; 
ctl_isolreqp = I'bO ; 
ctl_discardp = I'bO ; 

case (I'bl) 

IDLE : casez ( isopktreqn ) 



l»bl : idle = l»bl ; 

I'bO : begin 

waitforgnt = I'bl ; 
ctl_isolreqp = I'bl ; 
end 



//summit modcovoff -b 

default : idle = I'bx ; 
/ /summit modcovon -b 

endcase // casez { isopktreqn ) 



WAITFORGNT : casez ( arbgntp ) 
I'bO : waitforgnt = I'bl ; 
I'bl : begin 



//summit modcovoff -b 

default : waitforgnt = I'bx ; 
//summit modcovon -b 

endcase // casez ( arbgntp ) 



REFETCHWINDOW : casez ( { isorefetchp , ref etchtimeoutp } ) 

2 'boo : begin 

ref etchwindow = I'bl ; 
end 



begin 



ref etchwindow = 1 ' bl 
ctl_isogntp = I'bl 
end 



2 'blO : begin 

transmit = I'bl ; 
ctl_discardp = I'bl ; 
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40 



45 



50 



end 

2'b?l : begin 

transmit = I'bl ; 
5 end 

//summit modcovoff -b 

default : ref etchwindow = I'bx ; 
//summit mode o von -b 
10 endcase // casez ( { isorefetchp , 

ref etchtimeoutp } ) 



TRANSMIT : casez ( endxmitp ) 



l*bl : begin 

idle = I'bl ; 
2 0 ctl_confirmn = l*bO ; 

end 

l*bO : begin 

transmit = I'bl ; 

2 5 end 

//summit modcovoff -b 

default : transmit = I'bx ; 
//summit modcovon -b 

3 0 endcase // casez { endxmitp ) 



35 default : begin // snafu: if no state bit set 

idle = I'bx ; 
waitforgnt = I'bx ; 
ref etchwindow = I'bx ; 
transmit = I'bx ; 



ctl_isogntp = I'bx ; 
ctl_confirmn = I'bx ; 
ctl_isolreqp = I'bx ; 
ctl_discardp = I'bx ; 

end 

endcase // case (I'bl) 

end 
endmodule 
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